Informatik • Informatique 4/1997

The subject of the 1996 DBTA-Workshop was migration and coexistence in the Database World. Different approaches were shown: Prof. Zehnder advocated federated databases to replace step by step the aging integrated systems and support new applications in a flexible way. Dirk Jonscher pointed out the problem of bringing together data from different applications: His solution is an integration without data migration in an object-oriented integration framework. Walter Schnider reported of a migration of an IMS-Application to DB2 in a Swiss Bank. An approach of a step-by-step integration with data propagation between the two systems was chosen and works now after some initialproblems, thanks to highly motivated staff and loose time restrictions. Stefan Scherrer talked about his migration experience in a large insurance company: An OODBMS has been used to add functionality and flexibility to a DB2-System. The success of this project (in contrast to another project that was aborted) also relied on highly motivated staff and on the clear and immediate benefit from the project. Andreas Geppert finally presented the steps to a tool supporting the migration process from an RDBMS to an OODBMS: This tool is highly needed by the industry, and though some parts are quite readily definable, other parts of this transformation process will reSchweizer Informatiker Gesellschaft • Société Suisse des Informaticiens 54 INFORMATIK • INFORMATIQUE 4/1997main complex conceptional work not automatically performable. Am 21. Oktober 1996 fand inZürich besagter DBTA-Workshopstatt, der eine Diskussion angeris-sen hat, die sowohl die Welt derForschung als auch die Praxis be-wegt und auch in Zukunft fürDBTA ein Thema sein wird. Trotzdes zeitlichen Abstands hier einekleine Zusammenfassung diesesinteressanten Workshops.Prof. Dr. C. A. Zehnder (ETHZürich) eröffnete mit dem Thema“Migration von integrierten zuföderierten Systemen”. EineArbeitsgruppe an seinem Institutbeschäftigt sich mit dem ThemaRe-engineering, das den Studen-ten Probleme bereitet. Moderne,anwendernahe, flexible Sonderan-wendungen brauchen eine stabileBasis für die flexible Datennut-zung. Aufgabe des Rechenzen-trums ist es, diese langlebige Da-tenbasis zur Verfügung zu stellen– und zwar sowohl den aufwendi-gen Routineanwendungen wieauch den Sonderanwendungen.Dies ist in den heute noch laufen-den integrierten Systemen miteinheitlicher Datenbasis nichtmöglich. Ziel muss es daher sein,ein koordiniertes föderatives Sy-stem zu erstellen, d.h. ein System,in dem ein unternehmensweitesDatenschema entworfen und im-plementiert wird, das auf zusam-menpassende Teilschemata, dievon Applikationen unabhängig genutzt werden können, aufgeteiltwerden kann. Eine Ablösung derbestehenden Systeme ist bekanntermassen problematisch. Es empfiehlt sich, jeweils Teilbereicheaus dem integrierten System neu zu implementieren und mit dem bestehenden, reduzierten, altenintegrierten System zu koppeln.Dirk Jonscher (Uni Zürich) sprach zum Thema “Aufbau hete-rogener Datenbank-Föderationen mittels operationaler Integration”. Das Problem, das er behandelte, war gewissermassen das entgegengesetzte, verglichen mit Prof.Zehnder: Historisch sind in den letzten Jahren verschiedene Datenhaltungssysteme gewachsen(z.B. Dateisysteme, Datenbanksysteme, CAD-Systeme, Textdoku-mente), die jetzt für neue Applika-tionen Daten austauschen müssen.Statt der Migration (Konversionder Daten, Nachteil: Reimple-mentierung aller Anwendungen),der Definition von Austausch-formaten (Nachteile: Ressourcen-verschwendung, Konsistenz-/Aktualitätsprobleme u.a.) undDatenkatalogen (Nachteile: keineVerteilungstransparenz, Schnitt-stellenproblem u.a.) schlägt er dielogische Integration in föderiertenDatenbanksystemen vor: Man tutso, als ob man eine physische Mi-gration machte, aber die Datenbleiben real in den lokalen Daten-haltungssystemen, wodurch dielokalen Applikationen nicht be-troffen sind. Auch hier stehenmehrere Methoden zur Ver-fügung: Schemaintegration, ope-rationale Integration oder – amflexibelsten – Integrations-Frame-works. Das ProjektFRIEND1, imKern eine Zusammenarbeit vonINFO-B, IFI und GIUZ wird Pro-totypen dieses Integrationsansat-zes erarbeiten mit dem Ziel derVermarktung.Der Nachmittag begann mitzwei Referaten aus der unmittel-baren wirtschaftlichen Praxis. Zu-nächst berichtete Walter Schni-der (Systor AG) von einem seit1993 laufenden Migrationsprojektbeim Bankverein. Eine IMS-Ap-plikation (die Titelbuchhaltung –17 IMS-Segmenttypen aus demJahr 1982, 100 Mio Datensätze...) wird auf DB2 migriert. Anstossfür die Migration war u.a. ein “tri-viales” Problem: die IMS-Felder wurden zu klein für Yen-Beträge. Die ersten Probleme tauchtenbeim Ermitteln des Datenmodellsauf: Welche Felder werden noch benötigt? Was ist ihre Bedeutung? Ihr Inhalt? Welche Anforderungen müssen noch (zusätzlich) abgedeckt werden (eine unendliche Li-ste)? Das Mapping der IMS-Daten auf die DB2-Datenstruktur war wegen der unterschiedlichenDatenmodelle problematisch: verschiedene Strukturen in einem Segmenttyp, Homonyme/Synonyme, Wiederholungsgruppen, 1. Siehe INFORMATIK/INFORMA-TIQUE 5/1997 (erscheint Okto-ber 1997)Datenfelder mit verschiedenenBedeutungen, unterschiedlicheDatentypen. Die Datenkommuni-kation zwischen IMS und DB2 fürdie Übergangsphase wird mit demProdukt DPROR-NR ermöglicht:in einem ersten Schritt werden dieDaten von IMS zu DB2 propa-giert, in einer zweiten Phase wer-den Daten in beide Richtungenpropagiert (mit gewissen Konsi-stenzschwierigkeiten), in der letz-ten Phase ist das DB2-Systemsteuernd und propagiert die Datenzum IMS-System. Eine schwieri-ge Aufgabe war auch der DataCleanup: ungültige Daten, Berei-nigung numerischer Felder,Fremdschlüssel, Dateninkonsi-stenzen – die Datenqualität warmangelhaft, dadurch entstand einhoher RZ-Aufwand. Bei der Ein-führung gab es noch das Problemdes Zeitfensters für die Einfüh-rung: Nach erfolgreichem Pilotenwurde zu Pfingsten 1996 der ersteLoad durchgeführt. Wegen Per-formanceproblemen und derhohen Komplexität des Gesamt-systems sowie dem unterschätztenSpeicherbedarf musste nach einerWoche die Propagierung abge-stellt werden. Seit September, mitder Lieferung einer neuen DB2-Version, läuft das System aber.Voraussetzung für das Gelingendes Projekts waren klare Projekt-ziele, qualifizierte und motivierteMitarbeiter, hervorragendeKenntnisse des Ist-Systems, Ma-nagement-Unterstützung und: kein Termindruck!Stefan Scherrer (CSS Luzern)berichtete in seinem Referat “Erfolg = Migration * Coexistenz2” von einer Migration von einerDB2-Umgebung in Richtung einer OO-Umgebung. Anstoss war hier ein gescheitertes Reengi-neering-Projekt im Jahr 1992, die zur Befassung mit neuen Technologien geführt hat. Die alterndenApplikationen sind nicht mehr wartbar und müssen durch Neuentwicklungen abgelöst werden, die auch im härteren Wettbewerb die Krankenkasse besser rüsten.Eine eigentliche Strategie zur Ablösung aller Systeme besteht nicht: Es ist durchaus vorgesehen,stabile ältere Systeme mit den neuentwickelten laufen zu lassen.Bereits auf die Orbit 94 hin wurdeein Pilotprojekt mit OODBMS er-folgreich durchgeführt. Eine Eva-luation führte zur Entscheidungfür das Produkt O2 und zur Inden-tifikation von 2 Projekten: Pro-ductWorkbench (PWB) undSHARK. Bei PWB geht es um dieschnelle Entwicklung und Simu-lation von neuen Versicherungs-produkten. Dieses Projekt stelltesich aber als zu ambitiös heraus:Es fehlte eine Strategie für das be-stehende System, das operationaleSystem wäre sehr stark betroffengewesen, fachliche Ansprechpart-ner waren schwer zu finden. DasProjekt wurde sistiert. BeiSHARK war das Ziel, Rechnun-gen automatisiert zu verarbeiten,bessere Statistiken zu liefern, dieQualität der Verarbeitung zu ver-bessern und fachlich interessante-re Arbeitsplätze zu schaffen. Essollten ausgereifte Host-Moduleweiterverwendet werden, keinredundanter Code geschriebenwerden und die produktiven IS-Module nicht angepasst werden.Technisch wurde dieses Projektdurch eine schmale, funktionale,service-orientierte Schnittstelle zubestehenden IS begünstigt. Fach-lich wurde es von einer visionärenFachabteilung mit sehr hoher Mo-tivation getragen. Die Funktiona-lität war komplementär zum be-stehenden System. Sozial warfestzustellen, dass ein grosserDrang zur neuen Technologie be-stand und arbeiten am alten System “unbeliebt” waren – was zuSpannungen führte, die durch“Team Design” gemildert wurden. Eine umfassende Ausbildung, aber auch aufwendigesCoaching waren notwendig. Die Akzeptanz des Systems wurde durch den sofortigen wirtschaftli-chen Nutzen erreicht. Zentraler Erfolgsfaktor war auch die soziale Migration.Im letzten Referat der Tagung “Werkzeugunterstützte Migration relationaler Datenbestände in ob-jektorientierte” betonte AndreasGeppert (Uni Zürich) die Not-wendigkeit, Tools zur Unterstützung der Datenbankmigration zu entwickeln. Einige Gründe spre-chen bereits heute – und vermehrt in Zukunft – für OODBMS: die Schweizer Informatiker Gesellschaft • Société Suisse des Informaticiens INFORMATIK • INFORMATIQUE 4/1997 55Funktionalität, das Leistungsver-halten (besonders bei komplexenStrukturen), die Produktivität undWiederverwendbarkeit sowie dieEinheitlichkeit von Paradigmen.Gegen eine völlige Neuentwick-lung von Applikationen sprechendie prohibitiven Kosten, gegeneine paralleles Betreiben vonOODBMS und RDBMS der hö-here Aufwand. Das macht die Mi-gration, also die Transformationdes relationalen Schemas, die Mi-gration der Datenbestände und dieRe-Implementierung der Anwen-dungsprogramme und Schnittstel-len zu einer interessanten Alterna-tive. Eine manuelle Migration istaber aufwendig und fehler-anfällig, daher die Suche nach ei-ner systematischen Vorgehens-weise, die mit einem Werkzeugunterstützt werden kann. Der ersteSchritt muss eine semantischeAnreicherung des relationalenSchemas um seine Beziehungen.Dann werden die angereichertenrelationalen Schemata nach fixenRegeln transformiert. Der nächsteSchritt ist die Erweiterung desOO-Schemas bzgl. Extensionen,Persistenz und Verhalten und dasUmsetzen von Triggern und Kon-sistenzbedingungen sowie Sich-ten – es handelt sich hier um einenkomplexen Entwurfsprozess! Esschliesst sich die Datenmigrationan, die aus den Tupeln Objekte ge-nerieren. Neben der möglichstweitgehenden Unterstützung beidiesen Schritten der Migrationsollte ein Migrationswerkzeugauch die Migrationsgeschichteaufzeichnen, Überlegungen zualternativen Transformationen ge-statten, das partielle Rücksetzenvon Transformationen ermög-lichen und die Wiederverwend-barkeit unterstützen durch einRepository zur Verwaltung undManipulation von Entwurfsdatenund -metadaten. Das laufendeProjekt SYNDAMMA von O2und IFI Zürich hat bisher anhandvon Fallstudien Transformations-regeln erarbeitet, ein Migrations-werkzeug spezifiziert und Reposi-tories in einer Fallstudie verwen-det.Die abschliessende Podiums-diskussion konfrontierte die un-terschiedlichen, sich ergänzendenAnsätze der Migration. Es wurdenauch nochmals der soziale Aspektder Migration betont. Innovative Applications for Database Systems February, 3–4 1998, Zurich This workshop aims to bring to-gether researchers on DBMS andpractitioners who have experienceapplying innovative DBMS tech-nology. The latest research results as well as the issues and problems of practitioners will be discussed,what solutions they have devel-oped and what lessons they have learned. The topics of the workshop include but are not restrictedto: Data Visualization, Data Warehousing, Data Mining, Workflow Management and Groupware, Integration of existing DBMS, Tools and Applications, Delimitationbetween Application and DBMS, Event-Driven DBMS, Experienc-es with New Kinds of Standards,Models and Systems, Experienceswith New Kinds of Application Using Database Systems, Data-bases and Internet The workshopwill include a number of talks, a panel discussion as well as a post-